From dona@tridelta.com Thu Sep 05 09:40:47 1996 

Received: from wariat.apk.net (uucp@wariat.wariat.org [192.147.147.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id JAA24412 for <hfsig@tapr.org>; Thu, 5 Sep 1996 
09:40:46 -0500 (CDT) 

Received: (from uucp@localhost) by wariat.apk.net (8.7.5/8.7.3) id KAA19650 for 
hfsig@tapr.org; Thu, 5 Sep 1996 10:41:16 -0400 (EDT) 

>Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by 
tdi3.tridelta.com (8.6.9/8.6.9) with ESMTP id KAA13603 for <hfsig@tapr.org>; Thu, 
5 Sep 1996 10:18:39 -0400 

Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com 
(8.6.9/8.6.9) with ESMTP id KAA13603 for <hfsig@tapr.org>; Thu, 5 Sep 1996 
10:18:39 -0400 

Received: from donapc.tridelta.com (donapc.tridelta.com [192.160.168.70]) by 
sparcy.tridelta.com (8.7.1/8.7.1) with SMTP id KAA22674 for <hfsig@tapr.org>; Thu, 
5 Sep 1996 10:19:11 -0400 (EDT) 

Date: Thu, 5 Sep 1996 10:19:11 -0400 (EDT) 

Message-Id: <199609051419.KAA22674@sparcy.tridelta.com> 

X-Sender: dona@sparcy 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

To: hfsig@tapr.org 

From: dona@tridelta.com (Don Adams) 

Content-Type: text/plain; charset="us-ascii" 


I've been searching the internet for a few evenings. 

I found some abstracts 

at http://sun4.iaee.tuwien.ac.at/jb9495/ber20002.htm1 

http: //www.ee.ed.ac.uk/profiles/research/SaS/SaS-info.html 
that were interesting concerning a RAKE tracking filter. (?!) 
It claims to be a filter or corrolator 
that needed "no prior knowledge of the signal". and can 
correct multipath distortion. 


Does anyone know what this really is? 


Over and Out Don 


From karn@qualcomm.com Thu Sep 05 13:55:18 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA14834 for <hfsig@tapr.org>; Thu, 5 Sep 
1996 13:55:15 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
LAA12594; Thu, 5 Sep 1996 11:54:43 -0700 (PDT) 

Date: Thu, 5 Sep 1996 11:54:43 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199609051854.LAA12594@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199609051419.KAA22674@sparcy.tridelta.com> (dona@tridelta.com) 
Subject: Re: [HFSIG:1522] 


Don, 


I haven't looked at the article yet, but a RAKE receiver is a multichannel 
spread spectrum receiver that tracks the individual multipath components 
of a signal and then combines them before demodulation. We rely pretty 
heavily on them in Qualcomm's IS-95 CDMA system. 


The basic idea of a RAKE dates from the late 1950s. 


To resolve individual multipath components, the time delay between 
them must be at least one chip. This corresponds to a spreading 
bandwidth equal to or greater than the reciprocal of the delay. 


Alternatively, this corresponds to the spreading bandwidth being 
greater than the coherence bandwidth of the channel. Think of the 
channel as imposing a time-varying comb filter on your signal. If the 
signal is wide compared to the frequency interval between the "teeth" 
of the comb, then the comb is very unlikely to remove all of the 
Signal at once. This is frequency diversity in action. 


I don't know of any way that a RAKE receiver can be used ona 
narrowband signal. If the narrowband signal falls into one of the 
notches in the comb, nothing can bring it back. You then need other 
forms of diversity (time, space). 


Phil 


From Robert.Glassey@nmp.nokia.com Tue Sep 10 05:49:56 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id FAA17673 for <hfsig@tapr.org>; Tue, 10 Sep 1996 
05:49:44 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id LAA20659 for <hfsig@tapr.org>; Tue, 
10 Sep 1996 11:10:30 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AAQ55183107; Tue, 10 Sep 1996 11:11:48 +0300 
X-Openmail-Hops: 2 
Date: Mon, 9 Sep 96 18:09:52 +0100 
Message-Id: <H000029202618415@MHS> 
Subject: Johan's modem 
Mime-Version: 1.0 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=IS0O-8859-1; name="Johan's" 
Content-Transfer-Encoding: 7bit 


Hi, 


I downloaded the WAV files of Johan's modem waveforms. I've been able to 
load them into matlab, and I can see the 4 modulated tones, and I can 
see amplitude and phase modulation on each one, but I cannot extract any 
symbol timing or see any obvious constalation, no mater how I vary the 
reference carrier frequency. I can see paterns that repeat after a short 
time, but can't make any sense out of them. It would help if the data 


was longer and more random. 


Can you demodulate this waveform? if so how? What do you lock to? Is 
there a proper constalation? 


Cheers, 
Rob, GOVTQ 


From forrerj@peak.org Tue Sep 10 11:27:00 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAAQ0317 for <hfsig@tapr.org>; Tue, 10 Sep 1996 
11:26:58 -0500 (CDT) 

Received: from p05.tO0.monrotel.com (p05.tO.monrotel.com [198.68.25.38]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id JAA20048 for <hfsig@tapr.org>; Tue, 10 Sep 
1996 09:26:59 -0700 

Message-Id: <199609101626. JAA20048@PEAK .ORG> 

X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 10 Sep 1996 09:20:30 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1524] Johan's modem 


>Hi, 

> 

>I downloaded the WAV files of Johan's modem waveforms. I've been able to 
>load them into matlab, and I can see the 4 modulated tones, and I can 
>see amplitude and phase modulation on each one, but I cannot extract any 
>symbol timing or see any obvious constalation, no mater how I vary the 
>reference carrier frequency. I can see paterns that repeat after a short 
>time, but can't make any sense out of them. It would help if the data 
>was longer and more random. 

> 

>Can you demodulate this waveform? if so how? What do you lock to? Is 
>there a proper constalation? 

> 

>Cheers, 

> 

>Rob, GOVTQ 

> 

> 


Hi Rob, 


Pleased to see your interest in the waveforms. A few suggestions that may 
put you on the right track: 


I do have demodulators that goes with each of the sample waveforms, so rest 
assured, the signals can be demodulated and produce text-book constellations. 
All the waveforms are QPSK, so you need a QPSK demodulator(s). You may use 


coherent or non-coherent demodulation, and as the S/N is very good, you 
should have no problem to phase lock - at least I that is my experience. For 
detection, a matched filter works best, also keep in mind that these are 
RC-shaped pulses. 


All waveforms has 

a) a pre-amble, where the phase is stepped 90 degree per symbol (75 
baud rate), 

b) followed by a number of cycles 000/001/010/011/100/.... 


Since I have provided the baseband waveforms, here are the carrier tones that I 
used: 


Waveform 1: 1350 Hz ( single channel DQPSK) 
2: 1350/1500 Hz ( dual channel DQPSK) 
3: 1350/1500/1650/1800 ( quad channel DQPSK -- QUATOR) 


As you may notice form above, the tones are spaced at 2*Baudrate and there 
are eight phases on each carrier tone. 


I would suggest you start off with the single channel waveform, extract and 
study the I/Q waveform relationship, especially the pre-amble which will 
reveal a lot. 


For folks attending the DCC next week; a brief overview of QUATOR is planned 
for the HFSIG meeting. I'll show some ideas of how the bit assembly is to be 
done for achieving the time/frequency diversity. Keep in mind that things 
are experimental and things are wide open for suggestions/critisism. This is 
your opportunity to bring your ideas for further discussion. 


As far as the actual implementation, at least what I am doing; I have been 
using the PSA sound card platform thus far. This seems to have worked out 
exteremely well for coding various parts of the modem, i.e., for monitoring 
the workings of things like Costas loops and bit sync algorithms. 

For the future, however, I'm not sure which way I'll go. My experience with 
the new TI 320C31 DSK has been very encouraging - perhaps too little memory, 
but it is really nice for the task, the speed and dynamic range, and a high 
speed connection with the PC. This would make an ideal free-standing 
implementation. On the other hand, I'm tempted to develop on the PC using 
the soundblaster, but that would have no chance of ever getting the the ARQ 
mode to work. I will, however, be able to play with the broadcast and CSMA 
modes. 

I'll need to see how things develop - too much going on at the moment and 
the new modem have been on the shelf due to that. Would be nice to resume 
experimental work again. 


Much rambling, but hope this helps, 
--Johan 
From karn@qualcomm.com Tue Sep 10 18:03:54 1996 


Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA18220 for <hfsig@tapr.org>; Tue, 10 


Sep 1996 18:03:52 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
QAA07499; Tue, 10 Sep 1996 16:03:20 -0700 (PDT) 

Date: Tue, 10 Sep 1996 16:03:20 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199609102303.QAA07499@servo.qualcomm. com> 

To: hfsig@tapr.org 

Subject: coding progress 


Hello all, 


I've been rather quiet here of late so I thought I'd mention what I've 
been doing in my spare time over the past couple of weeks. 


I've continued to fine-tune my Viterbi decoder for speed and Eb/NO 
performance. 


My previous version uses the "register exchange" method to update the 
path histories. This limited the path history to 32 bits, the size of 

a long integer in C. This is barely adequate as the rule-of-thumb says 
that the path history should be at least 4-5 times the constraint length 
(K=7), longer if the code is going to be punctured to high rates. 


I rewrote my current version to use the traceback method. In this 
case, the path histories are saved all the way from the beginning of 
the packet. At the end of the packet, I “trace back" through the path 
memory to determine the decoded data. Although this version is 
packet-oriented at present, it shouldn't be too hard to modify to 
operate in a continuous stream mode where traceback is done every N 
bits (N >> K). 


I've also spent quite a bit of effort tuning up the Viterbi decoder 
for speed. Through a few more C coding tricks, I now have it running 
at 258 kb/s on a 133 MHz Pentium. (The compiler is GCC 2.7.2 with full 
optimization). 


Thanks to my success with fast Viterbi decoding I've gotten more 
interested of late in concatenated Reed-Solomon/Viterbi coding. These 
codes were used on the Voyager mission starting at Uranus, and they 
are now an integral part of digital satellite broadcasting (European 
DVB, US DSS). 


In terms of Eb/NO they perform about as well as sequential decoding 
but with more uniform computational effort. The BER curve for the 
Voyager code is a nearly vertical wall at a Eb/NO of about 2.5 dB. 
The Voyager outer code is a (255,223) RS code over GF(256), and the 
inner code is a rate 1/2 K=7 Viterbi-decoded convolutional code. DVB 
uses a shortened (204,188) RS outer code and a K=7 Viterbi inner code 
at various rates from 1/2 to 7/8, so it's not quite as strong as the 
Voyager code but is still quite good. 


This has gotten me interested in Reed-Solomon codes. I found some 
freely available C code on the net by Robert Morelos-Zaragoza and Hari 


Thirmoorthy of the University of Hawaii that does errors+erasures 
decoding of Reed-Solomon codes. I've been massaging it for speed and 
interface cleanliness. I now have it decoding the Voyager (255,223) RS 
code over GF(256) at about 850 kb/s with a full load of errors and 
erasures, and about twice that speed when the frame has no errors. 


I'll put both my new Viterbi decoder and the RS stuff up on my web page 
in a few days when I package it up. 


Phil 


From wb4gcs@amsat.org Tue Sep 10 19:34:25 1996 
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id TAA22911 for <hfsig@tapr.org>; Tue, 10 Sep 1996 
19:34:21 -0500 (CDT) 
Received: from PENTIUM by mh004.infi.net with SMTP 
(Infinet-S-3.3) id UAA28238; Tue, 10 Sep 1996 20:34:12 -0400 (EDT) 
Message-Id: <1.5.4.32.19960911003350.8c5091dc@infi.net> 
X-Sender: jsanford@infi.net 
X-Mailer: Windows Eudora Light Version 1.5.4 (32) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 10 Sep 1996 20:33:50 -0400 
To: hfsig@tapr.org 
From: Jim Sanford <wb4gcs@amsat.org> 
Subject: Re: [HFSIG:1525] Re: Johan's modem 


At 11:28 AM 9/10/96 -0500, you wrote: 

>>Hi, 

>> 

>>I downloaded the WAV files of Johan's modem waveforms. I've been able to 
>>load them into matlab, and I can see the 4 modulated tones, and I can 
>>see amplitude and phase modulation on each one, but I cannot extract any 
>>symbol timing or see any obvious constalation, no mater how I vary the 
>>reference carrier frequency. I can see paterns that repeat after a short 
>>time, but can't make any sense out of them. It would help if the data 
>>was longer and more random. 

>> 

>>Can you demodulate this waveform? if so how? What do you lock to? Is 
>>there a proper constalation? 

>> 

>>Cheers, 

>> 

>>Rob, GOVTQ 

>> 

>> 

> 

>Hi Rob, 

> 

>Pleased to see your interest in the waveforms. A few suggestions that may 
>put you on the right track: 

> 

>I do have demodulators that goes with each of the sample waveforms, so rest 


>assured, the signals can be demodulated and produce text-book constellations. 
>All the waveforms are QPSK, so you need a QPSK demodulator(s). You may use 
>coherent or non-coherent demodulation, and as the S/N is very good, you 
>should have no problem to phase lock - at least I that is my experience. For 
>detection, a matched filter works best, also keep in mind that these are 
>RC-shaped pulses. 


> 
>All waveforms has 

> a) a pre-amble, where the phase is stepped 90 degree per symbol (75 
>baud rate), 

> b) followed by a number of cycles 000/001/010/011/100/.... 

> 


>Since I have provided the baseband waveforms, here are the carrier tones that I 
>used: 


> 

>Waveform 1: 1350 Hz ( single channel DQPSK) 

> 2: 1350/1500 Hz ( dual channel DQPSK) 

> 3: 1350/1500/1650/1800 ( quad channel DQPSK -- QUATOR) 
> 


>As you may notice form above, the tones are spaced at 2xBaudrate and there 
>are eight phases on each carrier tone. 

> 

>I would suggest you start off with the single channel waveform, extract and 
>study the I/Q waveform relationship, especially the pre-amble which will 
>reveal a lot. 

> 

>For folks attending the DCC next week; a brief overview of QUATOR is planned 
>for the HFSIG meeting. I'll show some ideas of how the bit assembly is to be 
>done for achieving the time/frequency diversity. Keep in mind that things 
>are experimental and things are wide open for suggestions/critisism. This is 
>your opportunity to bring your ideas for further discussion. 

> 

>As far as the actual implementation, at least what I am doing; I have been 
>using the PSA sound card platform thus far. This seems to have worked out 
>exteremely well for coding various parts of the modem, i.e., for monitoring 
>the workings of things like Costas loops and bit sync algorithms. 

>For the future, however, I'm not sure which way I'll go. My experience with 
>the new TI 320C31 DSK has been very encouraging - perhaps too little memory, 
>but it is really nice for the task, the speed and dynamic range, and a high 
>speed connection with the PC. This would make an ideal free-standing 
>implementation. On the other hand, I'm tempted to develop on the PC using 
>the soundblaster, but that would have no chance of ever getting the the ARQ 
>mode to work. I will, however, be able to play with the broadcast and CSMA 
>modes. 

>I'll need to see how things develop - too much going on at the moment and 
>the new modem have been on the shelf due to that. Would be nice to resume 
>experimental work again. 


> 

>Much rambling, but hope this helps, 
> 

>--Johan 

> 


> 


Johan: 
PLEASE stay with the PSA chip set . 


73, Jim 
wb4gcs@amsat.org 
> 


From forrerj@peak.org Tue Sep 10 21:32:43 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id VAA27161 for <hfsig@tapr.org>; Tue, 10 Sep 1996 
21:32:40 -0500 (CDT) 

Received: from p05.tO0.monrotel.com (p04.tO.monrotel.com [198.68.25.37]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id TAA27279 for <hfsig@tapr.org>; Tue, 10 Sep 
1996 19:32:44 -0700 

Message-Id: <199609110232.TAA27279@PEAK.ORG> 

X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 10 Sep 1996 19:26:30 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1526] coding progress 


Phil, 


Nice progress - I am looking forward to downloading the latest versions of 
the decoders. 


A bit of feedback if you're interested - I have had a bash at converting the 
Fano decoder to run under MS VC++ version 4.0. This is for the NT/WIN95 
32-bit platform. I found that there are a number of routines that are common 
UNIX or GCC, but are missing from the MS libraries. I'll post something 
about this, but perhaps see your latest version first. 


Keep up the good work! 


--Johan 


>Hello all, 

> 

>I've been rather quiet here of late so I thought I'd mention what I've 
>been doing in my spare time over the past couple of weeks. 

> 

>I've continued to fine-tune my Viterbi decoder for speed and Eb/NO 
>performance. 

> 

>My previous version uses the "register exchange" method to update the 
>path histories. This limited the path history to 32 bits, the size of 
>a long integer in C. This is barely adequate as the rule-of-thumb says 
>that the path history should be at least 4-5 times the constraint length 
>(K=7), longer if the code is going to be punctured to high rates. 

> 


>I rewrote my current version to use the traceback method. In this 
>case, the path histories are saved all the way from the beginning of 
>the packet. At the end of the packet, I "trace back" through the path 
>memory to determine the decoded data. Although this version is 
>packet-oriented at present, it shouldn't be too hard to modify to 
>operate in a continuous stream mode where traceback is done every N 
>bits (N >> K). 

> 

>I've also spent quite a bit of effort tuning up the Viterbi decoder 
>for speed. Through a few more C coding tricks, I now have it running 
>at 258 kb/s on a 133 MHz Pentium. (The compiler is GCC 2.7.2 with full 
>optimization). 

> 

>Thanks to my success with fast Viterbi decoding I've gotten more 
>interested of late in concatenated Reed-Solomon/Viterbi coding. These 
>codes were used on the Voyager mission starting at Uranus, and they 
>are now an integral part of digital satellite broadcasting (European 
>DVB, US DSS). 

> 

>In terms of Eb/NO they perform about as well as sequential decoding 
>but with more uniform computational effort. The BER curve for the 
>Voyager code is a nearly vertical wall at a Eb/NO of about 2.5 dB. 
>The Voyager outer code is a (255,223) RS code over GF(256), and the 
>inner code is a rate 1/2 K=7 Viterbi-decoded convolutional code. DVB 
>uses a shortened (204,188) RS outer code and a K=7 Viterbi inner code 
>at various rates from 1/2 to 7/8, so it's not quite as strong as the 
>Voyager code but is still quite good. 

> 

>This has gotten me interested in Reed-Solomon codes. I found some 
>freely available C code on the net by Robert Morelos-Zaragoza and Hari 
>Thirmoorthy of the University of Hawaii that does errors+erasures 
>decoding of Reed-Solomon codes. I've been massaging it for speed and 
>interface cleanliness. I now have it decoding the Voyager (255,223) RS 
>code over GF(256) at about 850 kb/s with a full load of errors and 
>erasures, and about twice that speed when the frame has no errors. 

> 

>I'1ll put both my new Viterbi decoder and the RS stuff up on my web page 
>in a few days when I package it up. 

> 

>Phil 

> 

> 


From edu@kender.es Wed Sep 11 13:39:22 1996 

Received: from kender.es (kender.es [194.179.91.10]) by tapr.org (8.7.5/8.7.3/1.9) 
with ESMTP id NAAQ8124 for <hfsig@tapr.org>; Wed, 11 Sep 1996 13:38:55 -@500 (CDT) 
Received: from tximbo.kender.es (p4.kender.es [194.179.91.53]) by kender.es 
(8.7.5/8.7.3) with SMTP id UAA13498 for <hfsig@tapr.org>; Wed, 11 Sep 1996 
20:33:53 +0200 

Message-Id: <1.5.4.32.19960911213841.0067b2b4@kender.es> 

X-Sender: edu@kender.es (Unverified) 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 


Content-Type: text/plain; charset="us-ascii" 
Date: Wed, 11 Sep 1996 20:38:41 -0100 

To: hfsig@tapr.org 

From: Eduardo Jacob <edu@kender.es> 

Subject: Re: coding progress 


>A bit of feedback if you're interested - I have had a bash at converting the 
>Fano decoder to run under MS VC++ version 4.0. This is for the NT/WIN95 
>32-bit platform. I found that there are a number of routines that are common 
>UNIX or GCC, but are missing from the MS libraries. I'll post something 
>about this, but perhaps see your latest version first. 


I have read in DDJ that there is a port of GNU-C to Windows'95, 
perhaps you could use it. I don't remember very well but I think the missing 
parts were those related to the GUI. For dos perhaps DDJ could suit you. 


Eduardo EA2BAJ 
Eduardo, EA2BAJ 


From karn@qualcomm.com Wed Sep 11 17:41:33 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA18624 for <hfsig@tapr.org>; Wed, 11 
Sep 1996 17:41:31 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
PAA18109; Wed, 11 Sep 1996 15:40:58 -0700 (PDT) 

Date: Wed, 11 Sep 1996 15:40:58 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199609112240.PAA18109@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <1.5.4.32.19960911213841.0067b2b4@kender.es> (message from Eduardo 
Jacob on Wed, 11 Sep 1996 13:48:17 -0500 (CDT)) 

Subject: Re: [HFSIG:1529] Re: coding progress 


>>A bit of feedback if you're interested - I have had a bash at converting the 
>>Fano decoder to run under MS VC++ version 4.0. This is for the NT/WIN95 
>>32-bit platform. I found that there are a number of routines that are common 
>>UNIX or GCC, but are missing from the MS libraries. I'll post something 
>>about this, but perhaps see your latest version first. 


I'm a little confused by this, as the Fano decoder is just a low level 
subroutine that doesn't make use of anything elaborate in the 
operating environment. It should port to just about any C environment. 


> I have read in DDJ that there is a port of GNU-C to Windows'95, 
>perhaps you could use it. I don't remember very well but I think the missing 
>parts were those related to the GUI. For dos perhaps DDJ could suit you. 


There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with. 
A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web 
page. Are you saying there is specific support for windows 95 in graphics 
(not dos) mode? 


Phil 


From forrerj@peak.org Thu Sep 12 01:36:40 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id BAA12248 for <hfsig@tapr.org>; Thu, 12 Sep 1996 
01:36:38 -0500 (CDT) 

Received: from p01.tO.monrotel.com (p01.tO.monrotel.com [198.68.25.34]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id XAA12565 for <hfsig@tapr.org>; Wed, 11 Sep 
1996 23:36:45 -0700 

Message-Id: <199609120636.XAA12565@PEAK.ORG> 

X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Wed, 11 Sep 1996 23:30:28 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1530] Re: coding progress 


Hi Phil, 
Here are more specifics that may help; 


>>>A bit of feedback if you're interested - I have had a bash at converting the 
>>>Fano decoder to run under MS VC++ version 4.0. This is for the NT/WIN95 
>>>32-bit platform. I found that there are a number of routines that are common 
>>>UNIX or GCC, but are missing from the MS libraries. I'll post something 
>>>about this, but perhaps see your latest version first. 

> 

>I'm a little confused by this, as the Fano decoder is just a low level 
>subroutine that doesn't make use of anything elaborate in the 

>operating environment. It should port to just about any C environment. 

> 


I'm using VC version 4.0 (4.2 is the latest): 


Metrics.c: erf() .... not recognized perhaps there is an equivalent. 
M_SQRT2, M_LOG2E .... not recognized - these are UNIX/GCC natives. 
Sim.c: random() ... does'nt recognize this either. 


Of course, curses does'nt exsist, but one can work around that. Otherwise 
the function you use to parse your command-line arguments also doesn't have 
an equivalent. There are a few minor picky warnings regarding type casting 
that I agree with the compiler, but won't hurt. 


>> I have read in DDJ that there is a port of GNU-C to Windows'95, 
>>perhaps you could use it. I don't remember very well but I think the missing 
>>parts were those related to the GUI. For dos perhaps DDJ could suit you. 

> 

>There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with. 


Yes - the makefile for the Fano decoder and test programs all compile/link 
and execute 100% with DJGPP - either under DOS or a DOS box under WIN95. 


>A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web 
>page. Are you saying there is specific support for windows 95 in graphics 
>(not dos) mode? 

> 

>Phil 

> 

> 


I suspect he might be referring to that it is for generating Win95 "console" 
mode code, i.e., 32-bit programs that run in a Win95 DOS box. These do not 
use the Windows GUI functions. 


DJGPP is very slick and I like it a lot. My main objection with DJGPP, 
however, is when one venture into doing hardware access, which is what we 
used to used to do with DOS programs - DJGPP does that with with nasty old 
DPMI calls that I really discourage anyone to use. I personally feel that I 
would want to move away from DOS and things like DOS extenders and the 
limitations of 64K segments. The right way, in my humble opinion, is to bite 
the bullet and write your own VxDs to do that kind of thing using the native 
mechanisms provided by the operating system. This way one can control and 
guarantee interrupt latency and control the flow of data/control between 
Win95-based programs and real-time, low-level, device dependant code. Not 
that I think Win95 is all that great a piece of code, but I suspect that any 
code that will run under that platform will enjoy that much greater appeal 
in the ham community and get folks interested. If that was'nt the case, I 
would prefer to do all my work under Linux 

(my two-cents worth). 


--Johan 


From jmorriso@bogomips.com Thu Sep 12 02:20:42 1996 
Received: from orange.ConcordPacific.Com (root@orange.ConcordPacific.com 
[204.239.26.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id CAA13155 for 
<hfsig@tapr.org>; Thu, 12 Sep 1996 02:20:39 -0500 (CDT) 
Received: from bogomips.com (root@jmorriso.multiactive.com [204.239.26.200]) by 
orange.ConcordPacific.Com (8.6.12/8.6.12) with SMTP id AAA20114 for 
<hfsig@tapr.org>; Thu, 12 Sep 1996 00:20:59 -0700 
Received: by bogomips.com (Linux Smail3.1.29.1 #3) 
id m0v162e-O000TyBC; Thu, 12 Sep 96 00:18 PDT 
Message-Id: <m0v162e-000TyBC@bogomips. com> 
From: jmorriso@bogomips.com (John Paul Morrison) 
Subject: Re: [HFSIG:1530] Re: coding progress 
To: hfsig@tapr.org 
Date: Thu, 12 Sep 1996 00:18:28 -0700 (PDT) 
In-Reply-To: <199609112240.PAA18109@servo.qualcomm.com> from "Phil Karn" at Sep 
11, 96 05:55:46 pm 
X-Bogomips: 33.55 
Content-Type: text 


I'm a little confused by this, as the Fano decoder is just a low level 
subroutine that doesn't make use of anything elaborate in the 
operating environment. It should port to just about any C environment. 


> I have read in DDJ that there is a port of GNU-C to Windows'95, 
>perhaps you could use it. I don't remember very well but I think the missing 
>parts were those related to the GUI. For dos perhaps DDJ could suit you. 


There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with. 
A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web 
page. Are you saying there is specific support for windows 95 in graphics 
(not dos) mode? 


VV VV VV VV VV VV NV 


Cygnus support sponsored a port to Windows NT, plus compatibility 
libraries to make UNIX programs easy to port. Windows 95 implements 
some of the Windows NT (Win32) API, so it runs under that too 

(but not as well apparently). 


I think it can only do console mode (ie text), more code needs 
to be written so GCC can create GUI apps. 


BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM_ -- 
jmorriso@bogomips.com ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


From jtpjatae@bicc00.bi.ehu.es Thu Sep 12 05:47:31 1996 
Received: from bicc0O.bi.ehu.es (biccO0OQ.bi.ehu.es [158.227.65.40]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id FAA18245 for <hfsig@tapr.org>; Thu, 12 Sep 1996 
05:47:24 -0500 (CDT) 
Received: from bipt71.bi.ehu.es by bicc00.bi.ehu.es (AIX 3.2/UCB 5.64/4.03) 
id AA21376; Thu, 12 Sep 1996 12:49:14 +0100 
Message-Id: <9609121149 .AA21376@bicc00.bi.ehu.es> 
Comments: Authenticated sender is <jtpjatae@bicc00.bi.ehu.es> 
From: "Eduardo Jacob" <jtpjatae@bicc00.bi.ehu.es> 
Organization: ETSII y de IT, Bilbao, UPV/EHU 
To: hfsig@tapr.org 
Date: Thu, 12 Sep 1996 12:47:06 +0000 
Subject: Re: coding progress 
Reply-To: jtpjatae@bicc00.bi.ehu.es 
Priority: normal 
X-Mailer: Pegasus Mail for Win32 (v2.42a) 


> I have read in DDJ that there is a port of GNU-C to Windows'95, 
>perhaps you could use it. I don't remember very well but I think the missing 
>parts were those related to the GUI. For dos perhaps DDJ could suit you. 


VV VV 


There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with. 
A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web 
page. Are you saying there is specific support for windows 95 in graphics 
(not dos) mode? 


VVV WV 


For DOS I was speaking about DJGPP, not DDJ. Yes, the objective is 
to be able to build full GUI programs on Windows95 and NT. But I 
think it is not totally working. They are on Beta 16 There is 
information in 


ftp://f£tp.cygnus.com/pub/sac/gnuwin32 
I have read it in DrDobbs Journal pages 121-126. 
Eduardo EA2BAJ 


Eduardo Jacob - Area de Ingenieria Telematica 
Departamento de Electronica y Telecomunicaciones 


ETSII y de IT Tel: +34-(9)4-427 8055 
UPV / EHU Fax: +34-(9)4-441 4041 
Alda Urquijo s/n E-mail: jtpjatae@bi.ehu.es 
E-48013 - Bilbao (Spain) : 100021,2212 Compuserve 


From rwmcgwier@worldnet.att.net Thu Sep 12 07:00:36 1996 
Received: from mtigwc02.worldnet.att.net (mailhost.worldnet.att.net 
[204.127.129.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id HAA20169 for 
<hfsig@tapr.org>; Thu, 12 Sep 1996 07:00:33 -0500 (CDT) 
Received: from dad.ccr-p.ida.org ([207.146.141.132]) 
by mtigwc02.worldnet.att.net (post.office MTA v2.0 0613 ) 
with SMTP id AAA20415 for <hfsig@tapr.org>; 
Thu, 12 Sep 1996 12:00:00 +0000 
Message-ID: <3237FA46.2C96@worldnet.att.net> 
Date: Thu, 12 Sep 1996 07:55:50 -0400 
From: Robert McGwier <rwmcgwier@worldnet.att.net> 
Reply-To: rwmcgwier@worldnet.att.net 
Organization: N4HY Software 
X-Mailer: Mozilla 3.0b8Gold (Win95; I) 
MIME-Version: 1.0 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1526] coding progress 
References: <199609102303 .QAA07499@servo.qualcomm. com> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Phil Karn wrote: 
Hello all, 


I've been rather quiet here of late so I thought I'd mention what I've 
been doing in my spare time over the past couple of weeks. 


I've continued to fine-tune my Viterbi decoder for speed and Eb/NO 
performance. 


VV VV VV VV WV 


I saw a brilliant talk by Bob McEliece yesterday at the retirement bash 
for 

Neal Zierler. It was on Turbo Codes. I have a good understanding of 
what 

they are about now, maybe even better than McEliece ;-). He has built 
an 

intuitive understanding of WHY they work but cannot prove it. It is 
closely 

enough related to some stuff that I have done that I believe I CAN prove 
why they work and I have some techniques at my disposal that will allow 
me 

to accelerate their convergence. He claims that Viterbi claims they are 
the most significant development in N years (where N closely matches the 
number of years since he development the Viterbi decoder). You and I 
have 

had a conversation before on the telephone where I told the win of 

a posteriori estimation over dynamic programming based estimation. Let 
me 

reemphasize it here since it is at the very heart of Turbo codes. 
Dynamic 

programming (Viterbi decoding) finds the best PATH through the possible 
paths of symbols. What you want is to minimize the probability of 
making 

an error at each decision time given all the available evidence. It is 
this that Hidden Markov Models do (where the symbol is the Markov chain 
and the noisy channel is providing the Hidden ;-). Turbo codes have at 
their heart, HMM, and the decoder approximates the EM algorithm (which 
was first developed here at my company and the first rigorous proofs 
concerning it were made by Baum, Petrie, Soules, and Welch while working 
here). My experiments show that Turbo codes get <<<<<< within 1 dB of 
the Shannon limit and indeed get in a case I have tried to -0.6 dB Eb/NO 
>>>>>>>. You must climb onto the power curve on this it IS the future 
of coding. I posted this to everyone since you appear to be ham radio's 
primary instructor on coding these days and everyone could benefit by 
discussions. 


Bob 
KKKKIKKKIKK KAKA KAKA KAKA KAKA KAKA KKK K KKK K AKA K AIK IAA AAA K IKARIA AKIRA RIER ERIK 
x Robert W. McGwier, Ph.D. * Mathematician. Hobbies: Computers, 


Astronomyx 

* 64 Brooktree Rd. * Amateur Radio. Scouts: Council Commissioner 
: East Windsor, NJ 08520 x Post 995 Advisor, Troop 5700 Advancement, 

; (H) 609-443-8963 * Sanhican #2 (Brotherhood), Used to be a 

; (F) 609-924-3061 * Buffalo (NE-III-120). George Washington 

: (W) 609-279-6240 * Council. Brownie Troop 193 

* 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKAAKK 


From karn@qualcomm.com Thu Sep 12 13:23:12 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAAQ5011 for <hfsig@tapr.org>; Thu, 12 
Sep 1996 13:23:10 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
LAA28123; Thu, 12 Sep 1996 11:22:38 -0700 (PDT) 

Date: Thu, 12 Sep 1996 11:22:38 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199609121822.LAA28123@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199609120636.XAA12565@PEAK.ORG> (forrerj@peak.org) 

Subject: Re: [HFSIG:1531] Re: coding progress 


>Metrics.c: erf() .... not recognized perhaps there is an equivalent. 

> 

> M_SQRT2, M_LOG2E .... not recognized - these are UNIX/GCC natives. 
>Sim.c: random() ... does'nt recognize this either. 


Ah, those are both support files, not the actual decoder... 


erf() is in the UNIX math library, and should be in most PC subroutine 
libraries. It's the gaussian error function and is used to build the 

metric tables from "first principles", i.e., from a knowledge of the 
channel transition probabilities that are a function of Eb/NO and amplitude. 


M_SQRT2 and M_LOG2E are constants usually defined in <math.h>. M_SQRT2 
is sqrt(2) and M_LOG2E is log2(e). 


random() is a random number generator returning a value between 0 and 
Ox7fffffff inclusive. It's used to generate random bits and gaussian 
noise for test purposes. 


I note that the metric table can be built "offline" e.g., on a UNIX 
system or under DJGPP with a math package and then the table(s) 
included as compile-time data in the final program. Although the Fano 
decoder works best when you compute a metric table for the actual 
Eb/NO, I've found experimentally that you can use a fixed table 
computed for the worst Eb/NO you can handle (the computational cutoff 
rate, about 2.5 dB for rate 1/2) and then scale the incoming signal to 
maintain the constant noise level used to build the metric table. Much 
stronger signals will saturate the soft-decision samples and 
effectively degrade the decoder to hard decision decoding, but if 
they're that strong and clean in the first place that won't hurt 
anything. And signals noiser than 2.5 dB, of course, won't decode 
anyway. 


In other words, don't worry about the signal amplitude, it's the noise 
amplitude that counts. 


That's because the most important thing with the fano decoder is that 
the branch metrics on the correct path be generally positive. If the 


signal level is too low for the metric table in use, then the decoder 
will constantly back up thinking it has made an error when in fact 
it's on the best path. That's why it's important to scale the 
incoming signal to attempt to keep the noise level constant. That also 
explains why a signal AGC is a xvery bad* idea in Fano decoding, if it 
causes the noise level to vary. You want to keep the noise level 
constant and let the signal level vary if it has to. Again, let the 
signal saturate if it gets strong, that won't hurt anything. 


One of the big advantages of the Viterbi decoder over the Fano 
decoder, btw, is that the Viterbi decoder works for just about any 
metric table, as long as it's not "upside down", i.e., as long as its 
matched to the signal polarity. Even the set of integers 0-255 seems 
to work well. As long as the signal amplitude is such as to use at 
least a few bits of your sample dynamic range, the algorithm will 
function reasonably optimally. 


Phil 


From karn@qualcomm.com Thu Sep 12 13:25:25 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAAQ5063 for <hfsig@tapr.org>; Thu, 12 
Sep 1996 13:25:23 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
LAA28126; Thu, 12 Sep 1996 11:24:51 -0700 (PDT) 

Date: Thu, 12 Sep 1996 11:24:51 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199609121824.LAA28126@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <m0v162e-000TyBC@bogomips.com> (jmorriso@bogomips.com) 

Subject: Re: [HFSIG:1532] Re: coding progress 


Thanks for the info on GCC under windows. Of course, the question 
remains: is it possible to write anything approaching "real time" code 
under that system, as opposed to running under DOS on a bare machine? 
You can alleviate the problem with buffering (e.g., on a sound 

card). But I've already seen at least one machine running W95 (my 
laptop) that stutters occasionally like Max Headroom when playing back 
audio, probably because of missed interrupts. It never did that under 
W 3.1. 


Phil 


From karn@qualcomm.com Thu Sep 12 13:29:57 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAAQ5200 for <hfsig@tapr.org>; Thu, 12 
Sep 1996 13:29:54 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
LAA28130; Thu, 12 Sep 1996 11:29:23 -0700 (PDT) 

Date: Thu, 12 Sep 1996 11:29:23 -0700 (PDT) 


From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199609121829.LAA28130@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <3237FA46.2C96@worldnet.att.net> (message from Robert McGwier on Thu, 
12 Sep 1996 07:13:33 -0500 (CDT)) 

Subject: Re: [HFSIG:1534] Re: coding progress 


I agree, turbo codes are very exciting and they probably represent 
coding's last gasp. I've heard both Viterbi and McEliece speak at 
Qualcomm on this subject. 


But there's a catch. Patents are flying in this area faster than 
bullets in a battlefield, and since I'm interested in writing free 
software the last thing I want is to be sued. Fano decoders, Viterbi 
decoders, Reed-Solomon decoders and concatenated codes have been 
around for 25-35 years and are clearly in the public domain. 


Phil 


From forrerj@peak.org Thu Sep 12 16:16:56 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id QAA12990 for <hfsig@tapr.org>; Thu, 12 Sep 1996 
16:16:52 -0500 (CDT) 

Received: from p06.tO.monrotel.com (p06.tO.monrotel.com [198.68.25.39]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id OAA18381 for <hfsig@tapr.org>; Thu, 12 Sep 
1996 14:17:00 -0700 

Message-Id: <199609122117 .0AA18381@PEAK .ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 12 Sep 1996 14:10:55 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1532] Re: coding progress 


John, 


I checked this out and looks like an interesting development - they are at 
Beta 16, but still is a cross-port running on a Linux platform. The native 
compiler for the Win95 platform is still in it's infancy - will be a while 
if I interpret things correctly. 


>> There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with. 
>> A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web 
>> page. Are you saying there is specific support for windows 95 in graphics 
>> (not dos) mode? 

> 

>Cygnus support sponsored a port to Windows NT, plus compatibility 

>libraries to make UNIX programs easy to port. Windows 95 implements 

>some of the Windows NT (Win32) API, so it runs under that too 


>(but not as well apparently). 

> 

>I think it can only do console mode (ie text), more code needs 
>to be written so GCC can create GUI apps. 

> 

>> 

>> Phil 

>> 


>BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM_ -- 
> Jmorriso@bogomips.com ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


--Johan 


From jmorriso@bogomips.com Thu Sep 12 23:29:31 1996 
Received: from orange.ConcordPacific.Com (root@orange.ConcordPacific.com 
[204.239.26.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA10218 for 
<hfsig@tapr.org>; Thu, 12 Sep 1996 23:29:28 -0500 (CDT) 
Received: from bogomips.com (root@jmorriso.multiactive.com [204.239.26.200]) by 
orange.ConcordPacific.Com (8.6.12/8.6.12) with SMTP id VAA18942 for 
<hfsig@tapr.org>; Thu, 12 Sep 1996 21:29:47 -0700 
Received: by bogomips.com (Linux Smail3.1.29.1 #3) 
id mOviPql-000TswC; Thu, 12 Sep 96 21:27 PDT 
Message-Id: <m0v1iPql-000TswC@bogomips. com> 
From: jmorriso@bogomips.com (John Paul Morrison) 
Subject: Re: [HFSIG:1538] Re: coding progress 
To: hfsig@tapr.org 
Date: Thu, 12 Sep 1996 21:27:29 -0700 (PDT) 
In-Reply-To: <199609122117 .OAA18381@PEAK.ORG> from "Johan Forrer" at Sep 12, 96 
04:33:23 pm 
X-Bogomips: 33.55 
Content-Type: text 


John, 


I checked this out and looks like an interesting development - they are at 
Beta 16, but still is a cross-port running on a Linux platform. The native 
compiler for the Win95 platform is still in it's infancy - will be a while 
if I interpret things correctly. 


VV VVVV VV VV 


--Johan 


GCC is not yet self-hosting on Win95/WinNT (ie can recompile itself) 
but it does compile programs (actually, I think it will build itself 
with some manual assistance). Also, I don't think Windows 95 is the 
primary goal of the Win32 port. It's meant to work with Windows NT; 


the Windows 95 support is a secondary bonus because it supports 
some of the Win32 api, but not others. 


Depending on what you want to do, DJGPP programs work in Windows 95. 
I was able to run the DJGPP version of NOS (which I cross-compiled in 
Linux) in Windows 95, and use SLIP. Packet drivers should work too. 


BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM_ -- 
jmorriso@bogomips.com ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


From sailer@ife.ee.ethz.ch Fri Sep 13 09:34:46 1996 

Received: from ife.ee.ethz.ch (ife-ife2.ee.ethz.ch [129.132.25.129]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id JAAQ3507 for <hfsig@tapr.org>; Fri, 13 Sep 1996 
09:34:36 -0500 (CDT) 

Received: from eldrich.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.25.145]) by 
ife.ee.ethz.ch (8.7.5/8.7.5) with SMTP id QAAQ2316 for <hfsig@tapr.org>; Fri, 13 
Sep 1996 16:34:31 +0200 (MET DST) 

Sender: sailer@ife.ee.ethz.ch 

Message-ID: <323970F5.35E5@ife.ee.ethz.ch> 

Date: Fri, 13 Sep 1996 16:34:29 +0200 

From: Thomas Sailer <sailer@ife.ee.ethz.ch> 

Organization: IfE 

X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) 

MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1536] Re: coding progress 

References: <199609121824.LAA28126@servo.qualcomm. com> 

Content-Type: text/plain; charset=us-ascii 

Content-Transfer-Encoding: 7bit 


card). But I've already seen at least one machine running W95 (my 
laptop) that stutters occasionally like Max Headroom when playing back 
audio, probably because of missed interrupts. It never did that under 
W 3.1. 

This seems to be a different problem. We're currently working 

on Windows support for PC/FlexNet, and Baycom type modems and (U)SCC 
cards at higher speeds run already, which have rather hard 

requirements wrt interrupt latency. 

Not that I am a Windoze advocat... 


VV VV 


Tom 


From forrerj@peak.org Mon Sep 23 10:49:48 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA20613 for <HFSIG@TAPR.org>; Mon, 23 Sep 1996 
10:49:47 -0500 (CDT) 

Received: from p03.tO.monrotel.com (p00.tO.monrotel.com [198.68.25.33]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id IAA27272 for <HFSIG@TAPR.org>; Mon, 23 Sep 


1996 08:49:58 -0700 

Message-Id: <199609231549.IAA27272@PEAK.ORG> 
X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Date: Mon, 23 Sep 1996 08:45:26 -0800 

To: HFSIG@tapr.org 

From: forrerj@peak.org (Johan Forrer) 
Subject: DCC 1996 


Hi All, 
I will shortly post a short summary of my impressions of the recent DCC. 


First; let me thank the hosts; BEARS (Boeing Employees Amateur Radio 
Society) for all the kind and generous hospitality. The conference venue was 
excellent, food great, and we were kept entertained and happy. 


I also wish to thank ARRL and the folks from TAPR for all the hard work that 
have gone into making such an event successful. Just to illustrate; the 
proceedings consists of some 256 double-sided pages with excellent technical 
content, for example, two outstanding contributions on 1.2 Mbit/s digital 
tranceivers by Matjaz Vidmar, S53MV - complete with schematics. 


The interest in HF digital was heartwarming and so was the HFSIG meeting (at 
least from where I was standing on the other side of the podium!) The topic 
this time was woven around past discussions we have had on HFSIG regarding 
HF Channel simulation: Tom McDermot did an excellent presentation of the 
mechnics involved in simulation using the Watterson model, that I followed 
with showing a number of "doppler grams", courtesy of Peter Martinez, G3PLX. 
These are really unique and worth seeing. A brief overview of software for 
the DSP-93 and a demo running this implementation of the Watterson 
ionospheric model, concluded this part of the meeting. I also presented an 
outline of the work that I have been doing on QUATOR. 


More to follow later on the DCC. 


I also need to prepare a posting on some of the recent developments on the 
slow-speed BPSK scene - this involves some innovative coding that are 
especially suited for such narrow-band systems that are limited by human 
typing speeds - quite contrary to the trend to building error-correcting 
codes. 


73's till later. 
--Johan Forrer, KC7WW 


From forrerj@peak.org Tue Sep 24 10:50:07 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA04954 for <HFSIG@TAPR.ORG>; Tue, 24 Sep 1996 
10:50:05 -0500 (CDT) 

Received: from p06.tO.monrotel.com (p06.tO.monrotel.com [198.68.25.39]) by 


PEAK.ORG (8.6.13/8.6.7) with SMTP id IAAQ09227 for <HFSIG@TAPR.ORG>; Tue, 24 Sep 
1996 08:50:03 -0700 

Message-Id: <199609241550.IAAQ9227@PEAK.ORG> 
X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 24 Sep 1996 08:45:42 -0800 

To: HFSIG@tapr.org 

From: forrerj@peak.org (Johan Forrer) 
Subject: G3PLX's Dopplergrams 


Hi, 


I have had someone ask to post further details about how the dopplergrams 
that I showed at the DCC were produced. 


Actually it's an old trick used in monitoring meteor scatter and other weak 

Signals; monitor a known transmission that you know arrives via the ionosphere. 
Peter's examples where recorded on 21 MHz, 17.7 MHz, 10.2 MHz, 7.7 

MHz, and 3.5 MHz. Then a slice of the receiver's audio passband, say around 

1 kHz are converted into a stream of I/Q values at 10 mS intervals and that 

run through an FFT to produce the images. Peter then describes the display 

as follow: 


"These images are time/frequency plots, with signal-level encoded 

as the brightness. They were originally 16-level, and the signal 
level is logarithmic with 3.75dB per grey-step, so that the full 
dynamic range is 60dB. In the vertical direction there are 256 pixels 
representing the frequency axis, and in most of the images there 

are 640 pixels horizontally for the time-axis." 


The result appears like a strip chart with Doppler shift on the vertical 
axis, and time along the horizontal axis. The doppler axis typically spans 
256 pixels that represent either 25 Hz, 12.5 Hz, or 6.25 Hz Doppler, i.e., 
tracking some rather narrow frequency disturbances. The time axis typically 
Spans over several hours, often a full day and night. In such cases band 
"closing" and "openings" are distinct and reveal several complex ionospheric 
mechanics such as meteor pings, sporadic E, F layer propagation, and rays 
splitting into (0)rdinary and (X)traordinary components. Even reflections 
from aircraft can be identified. 


Peter indicated that he will be publishing some of this work and that would 
be something to look forward to. We are most grateful for his permission to 
show some examples of this work at the DCC. 


--Johan 


From nuucp@ihig2.firewall.lucent.com Tue Sep 24 12:02:50 1996 

Received: from ihgw2.lucent.com (ihgw2.att.com [207.19.48.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAAQ6824 for <hfsig@tapr.org>; Tue, 24 Sep 1996 
12:02:49 -0500 (CDT) 

To: hfsig@tapr.org 


Received: by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) 
id LAAQ5191; Tue, 24 Sep 1996 11:58:36 -0500 

Date: Tue, 24 Sep 1996 11:58:36 -0500 

From: nuucp@ihig2.firewall.lucent.com 

Message-Id: <199609241658.LAA05191@ihig2.firewall.lucent.com> 

Subject: UUCP command execution failed 

Content-Type: text 

Apparently-To: tapr.org!hfsig@ihig2.firewall.lucent.com 


Your UUCP remote execution request 'igbAbb3e' (9/24-11:58:35) 
failed on system ‘ihig2'. 

Your request: rmail bighorn.dr.lucent.com! grb 

Reason for failure: command exited with exit code 1 


From karn@unix.ka9q.ampr.org Fri Sep 27 03:20:02 1996 

Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 

tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAA15212 for <hfsig@tapr.org>; Fri, 27 

Sep 1996 03:20:00 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id BAA16824; 

Fri, 27 Sep 1996 01:19:42 -0700 (PDT) 

Date: Fri, 27 Sep 1996 01:19:42 -0700 (PDT) 

Message-Id: <199609270819 .BAA16824@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: hfsig@tapr.org, tcp-group@ucsd.edu 

Cc: robert@spectra.eng.hawail.edu, harit@spectra.eng.hawaii.edu, 
simon@augean.eleceng.adelaide.edu.au 

Subject: Reed-Solomon encoder/decoder code available 


Hi. I've just released the Reed-Solomon software I've been working on 
lately. 


The software can encode and decode Reed-Solomon codes with symbol 
sizes ranging from 242 to 2416 bits. The default parameters are for 
the (255,223) code with 8-bit symbols that was used on the Voyager-2 
spacecraft at Uranus and Neptune. 


The files are as follows: 

http: //www.qualcomm.com/people/pkarn/feccode/rs-readme 

http://www. qualcomm.com/people/pkarn/feccode/rs.zip 

http: //www.qualcomm.com/people/pkarn/feccode/rs.tar. gz 

I've also updated my ham radio digital communications page 

(http: //www.qualcomm.com/people/pkarn/ham.html) with pointers to these 
files. Enjoy! 


Phil 


From jsanford@mailhost.infi.net Fri Sep 27 07:10:14 1996 
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org 


(8.7.5/8.7.3/1.9) with ESMTP id HAA20137 for <hfsig@tapr.org>; Fri, 27 Sep 1996 
07:10:12 -0500 (CDT) 
Received: from PENTIUM by mh004.infi.net with SMTP 
(Infinet-S-3.3) id IAA13490; Fri, 27 Sep 1996 08:10:20 -0400 (EDT) 
Message-ID: <324BBF42.6A57@mailhost.norfolk.infi.net> 
Date: Fri, 27 Sep 1996 07:49:22 -0400 
From: Jim Sanford <jsanford@mailhost.infi.net> 
Reply-To: WB4GCS@AMSAT.ORG 
Organization: wb4gcs@amsat.org 
X-Mailer: Mozilla 3.0 (Win16; U) 
MIME-Version: 1.0 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1544] Reed-Solomon encoder/decoder code available 
References: <199609270819.BAA16824@unix.ka9q.ampr.org> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Phil Karn wrote: 


> 

> Hi. I've just released the Reed-Solomon software I've been working on 
> lately. 

> 

> The software can encode and decode Reed-Solomon codes with symbol 

> sizes ranging from 242 to 2416 bits. The default parameters are for 
> the (255,223) code with 8-bit symbols that was used on the Voyager-2 
> spacecraft at Uranus and Neptune. 

> 

> The files are as follows: 

> 

> http://www. qualcomm.com/people/pkarn/feccode/rs-readme 

> http://www.qualcomm.com/people/pkarn/feccode/rs.zip 

> http: //www.qualcomm.com/people/pkarn/feccode/rs.tar. gz 

> 

> I've also updated my ham radio digital communications page 

> (http: //www.qualcomm.com/people/pkarn/ham.html) with pointers to these 
> files. Enjoy! 

> 

> Phil 

Phil: 

THANK YOU! 


All the best 73, Jim wb4gcs@amsat.org 


From forrerj@peak.org Fri Sep 27 10:12:18 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA25641 for <hfsig@tapr.org>; Fri, 27 Sep 1996 
10:12:16 -0500 (CDT) 

Received: from p05.tO0.monrotel.com (p05.tO.monrotel.com [198.68.25.38]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id IAAQ4514 for <hfsig@tapr.org>; Fri, 27 Sep 
1996 08:12:27 -0700 

Message-Id: <199609271512.IAAQ4514@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 


Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 27 Sep 1996 08:08:29 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1544] Reed-Solomon encoder/decoder code available 


Phil, 


>Hi. I've just released the Reed-Solomon software I've been working on 
>lately. 


Great! I have just the application for it. 
Thanks much. 
--Johan 


From jsanford@mailhost.infi.net Fri Sep 27 12:06:17 1996 
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAAQ0251 for <hfsig@tapr.org>; Fri, 27 Sep 1996 
12:06:16 -0500 (CDT) 
Received: from PENTIUM by mh004.infi.net with SMTP 
(Infinet-S-3.3) id NAA28883; Fri, 27 Sep 1996 13:06:24 -0400 (EDT) 
Message-ID: <324C0980.14F1@mailhost.norfolk.infi.net> 
Date: Fri, 27 Sep 1996 13:06:08 -0400 
From: Jim Sanford <jsanford@mailhost.infi.net> 
Reply-To: WB4GCS@AMSAT .ORG 
Organization: wb4gcs@amsat.org 
X-Mailer: Mozilla 3.0 (Win16; U) 
MIME-Version: 1.0 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1544] Reed-Solomon encoder/decoder code available 
References: <199609270819.BAA16824@unix.ka9q.ampr.org> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


> 

> The files are as follows: 

> 

> http://www. qualcomm.com/people/pkarn/feccode/rs-readme 

> http://www.qualcomm.com/people/pkarn/feccode/rs.zip 

> http: //www.qualcomm.com/people/pkarn/feccode/rs.tar. gz 

> 

> Phil 

Phil: 

What's the rs.zip and rs.tar.gz files -- different coding of same thing? 


Netscape choked on the .gz file . 
(Windoze version) 


thanks, Jim 


From rwhiting@winternet.com Sun Sep 29 20:04:49 1996 
Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.5]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA18451 for <hfsig@tapr.org>; Sun, 29 
Sep 1996 20:04:46 -0500 (CDT) 
Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id UAAQ2558 
for <hfsig@tapr.org>; Sun, 29 Sep 1996 20:04:42 -0500 (CDT) 
Date: Sun, 29 Sep 1996 20:04:42 -@500 (CDT) 
Posted-Date: Sun, 29 Sep 1996 20:04:42 -0500 (CDT) 
Message-Id: <199609300104.UAAQ2558@icicle.winternet.com> 
Received: from ppp-67-117.dialup.winternet.com(204.246.67.117) by 
icicle.winternet.com via smap (V2.0a1) 
id xma002539; Sun, 29 Sep 96 20:04:28 -0500 
X-Sender: rwhiting@mail.winternet.com 
X-Mailer: Windows Eudora Light Version 1.5.2 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 
From: CDrentea@aol.com (by way of Rick Whiting <xrwhiting@winternet.com>) 
Subject: New Book 


I came across a new book you may want to take a look at: Digital 
Communications Techniques - Signal Design and Detection by Simon, Hinedi and 
Lindsey - ISBN # 0-13-200610-3. It has been recently published by Prentice 
Hall and costs about $82 - 10% from Barnes and Noble. 


Very comprehensive. Although this information exists partially in other 
books, the book presents the methods of coherent, noncoherent, partially 
coherent, and differentially coherent detection for various binary and M-ary 
coded and uncoded modulation techniques (BPSK, QPSK, MSK, MFSK, QASK, QAM, 
etc) that can be applied to the design of uncoded systems while the 
Ro-criterion (channel throughput in bits/sec/Hz) and bit error probability 
are used as the methodology for designing efficient coded digital radio 
communications circuits. The book has absolutely nothing on propagation 
phenomena per say (it would be too good to be true), but presents the 
communication channel methodically and much like an OSI-ISO seven layer 
digital communications model (old stuff for data communications in WANs and 
LANs, but a very "novel" idea for radio data communications). 


Key concepts include scalar, vector, and waveform communications over the 
additive nonwhite (colored) Gaussian noise channels. Communications via 
Rayleigh and Rician fading (due to multipath) channels are also presented. 


Enjoy! 


From karn@unix.ka9q.ampr.org Mon Sep 30 03:55:29 1996 

Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAAQ9525 for <hfsig@tapr.org>; Mon, 30 
Sep 1996 03:55:27 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id BAA23664; 
Mon, 30 Sep 1996 01:54:48 -0700 (PDT) 


Date: Mon, 30 Sep 1996 01:54:48 -0700 (PDT) 

Message-Id: <199609300854.BAA23664@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: Jim Sanford <jsanford@mailhost.infi.net> 

CC: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <324C0980.14F1@mailhost.norfolk.infi.net> (message from Jim 
Sanford on Fri, 27 Sep 1996 12:15:17 -0500 (CDT)) 

Subject: Re: [HFSIG:1547] Re: Reed-Solomon encoder/decoder code available 


>What's the rs.zip and rs.tar.gz files -- different coding of same thing? 

Yes. The rs.zip file is a PKZIP-format file (primarily for DOS users) and 

the rs.tar.gz file is a GZIP-compressed tar archive (primarily for UNIX users). 
I say "primarily" because tools to read each format do exist on both platforms. 
Note that the test driver program is intended for a UNIX environment 

and may require some tweaking to run under DOS, e.g, the library 


routines called to generate random numbers may have to be changed. 


The actual RS subroutines are self-contained and should compile 
cleanly on any system that supports ANSI C. 


Phil 


